いまのうちから AWS Systems Manager で利用している AmazonEC2RoleforSSM ポリシーを見直しましょう！
園部です。
Systems Manager（以下 SSM）では、マネージドポリシーがいくつか用意されています。中でも以前からあった AmazonEC2RoleforSSM は多くの機能が利用可能なため、ご利用の方も少なくないかと思います。ただし、このポリシーは若干広い権限を保有しているため、昨年よりシンプルなポリシーが提供され、移行が推奨されました。
改めて AWS Blog でポリシーの見直しについて解説および作業例が紹介されていましたので、読み進めながら自分の環境をチェック＆改善したいと思います！
まだやっていないなという方は、是非状況の可視化（対象ポリシーの利用状況）だけでも実施されることをお勧めいたします。
前置き
何がおきるの？
明確な時期は確定していませんが AmazonEC2RoleforSSM が非推奨となるとドキュメントに記載がされています。翻訳によっては廃止と訳される場合もありますが、非推奨が正しい表現のようです。
AWS Systems Manager の AWS マネージドポリシー
具体的には、新規および既存で利用していたリソースからポリシーをデタッチしたタイミングで再度アタッチすることが出来なくなるようです。
Plan for replacing the AmazonEC2RoleforSSM policy
この動作は、他の非推奨となったポリシーと同様の流れとなるようです。
既存のリソースは継続して利用することが可能ではありますが、新規に利用する際に NG となるようです。 冒頭の AWS Blog 記事内でも記載がありますが CFn や 起動テンプレートなどで普段意識せずに利用している際は要注意です。ある日、正しい動作がしなくなる可能性があります。ユーザー側では意図的に何もしていないため、トラブルシューティングに時間を有するリスクがあります。
どうしたらいい？
非推奨となる前に、置き換えを進めることがベターかと思います。（非推奨となっても既存リソースは継続利用が可能なため必須ではないとも考えられますが、トラブルの原因となりそうです）
AWS Blog 記事内では置き換えを進めるフェーズとして以下が紹介されています。
- フェーズ1：必要なポリシーを定義する
- フェーズ2：ポリシー参照を更新する
- フェーズ3：既存のIAMエンティティを更新する
個人的には フェーズ１ を行う前に、現状どこで使っているかを確認しインパクトを把握した上で、本来必要なポリシーを検討・定義し、フェーズ２以降の置き換えを実施するのが良いかと思います。（既に把握されている方には不要な作業です。）今回は フェーズ3 で紹介される IAM ポリシーを利用している IAM リソースをまずは洗い出してみてから、紹介されている内容をやってみたいと思います。
やってみた
フェーズ0
AWS Config マネージドルールである iam-policy-blacklisted-check を利用して AmazonEC2RoleforSSM ポリシーを利用している IAM リソース（ユーザー、グループ、ロール）を洗い出していきます。
実施する前に、設定を確認します。
AWS Config >>> 設定 >>> グローバルリソース (AWS IAM リソースなど) を含める にチェックがされていることを確認
ルール >>> ルールを追加 を選択
iam-policy-blacklisted-check ルールを検索し選択
ルールのパラメータ で対象とするパラメータを以下のように置き換えます。
変更前） arn:aws:iam::aws:policy/AdministratorAccess
変更後） arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM
保存 を選択
しばらくすると評価が実行され結果が表示されます。
6個ほど検出されました（ちょっと多いですね。検証アカウントとはいえ。。
アクセスアドバイザーを利用するなどして AmazonEC2RoleforSSM で、どのようなアクションやサービスを利用しているかを確認しておきます。 以下の例では、AWS Directory Service は利用していませんが他は満遍なく利用していることが表示されています。
洗い出しと用途が把握できたら、次は AmazonEC2RoleforSSM に置き換えるポリシーとしてどのような権限が必要かを整理し定義していきます。
フェーズ１
置き換えるために、他のマネージドポリシーで担保できるアクションがどれで、カスタムで作成しなければならないアクションが何かについて AWS Blog 記事内で詳細に説明がされています。このマトリックスがあるだけでも大変助かるのではないでしょうか。
(引用： Applying managed instance policy best practices)
先のアクセスアドバイザーで確認した IAM ロールであれば以下に置き換える必要があります。
- AmazonSSMManagedInstanceCore
- コマンド結果を S3 へ出力するカスタムポリシー
- CloudWatchAgentServerPolicy （← 既にアタッチ済み）
フェーズ2
起動テンプレートや CFn で AmazonEC2RoleforSSM を指定したり、利用しているリソースを指定している場合は変更を行います。以下は起動テンプレートでインスタンスプロファイルとして指定している例で、このあとのフェーズ3 でも対応可能ではありますが、このような形で利用している部分で置き替えが必要な場合は変更しています。
フェーズ3
直接ポリシーを指定しているようなケースは フェーズ2 で対応を行い、ここでは大部分のケースである IAMリソース（ユーザー、グループ、ロール）にアタッチされているケースへの対応を行います。具体的には フェーズ1 で置き換えを検討・定義したポリシーをアタッチし AmazonEC2RoleforSSM をデタッチします。 AWS Blog 記事内では AWS Config ルールと SSM Automation による修復アクションを CFn で作成し実行する例が紹介されています。
CFn テンプレートなどが Github で公開されています。今回は CFn でのスタック作成部分は割愛させていただき、実行された結果だけ紹介します。
AWS Config に二つルールが追加されます。 Role の方は先に作成したルールと同じく6つ検出しています。
一つの IAM ロールに対して、修復アクションを実行してみます。
実行前の画面ショットを撮り忘れたので信憑性に欠けますが、先ほど アクセスアドバイザーで参照した IAM ロール内で AmazonEC2RoleforSSM がデタッチされ AmazonSSMManagedInstanceCore が新しくアタッチされています。
さいごに
今回は AWS Blog で紹介されていた非推奨が予定されている SSM のマネージドポリシーである AmazonEC2RoleforSSM を置き換える記事を読みながらやってみました。 環境によっては、フェーズ3 で一気にアタッチとデタッチするのはリスクがともないますが、現状の把握・置き換えるポリシーの検討など、非常に参考となる内容が説明されています。
AmazonEC2RoleforSSM の置き換え対応を計画されている方のお役に立てれば幸いです。（あと５つも早く置き換えないとな。。
